Debian: this commit breaks a lot of tests on loong64 since our rustc build is
still based on LLVM-17. This revert should be dropped once we switch over to
LLVM 18.
In Rust, library filenames include a version-specific hash to help
the run-time linker find the correct version. Unlike in C/C++, the
compiler looks for all libraries matching a glob that ignores the
hash and reads embedded metadata to work out versions, etc.
The upshot is that there is no need for the usual "libfoo.so ->
libfoo-1.2.3.so" symlink common with C/C++ when building with Rust,
and no need to communicate an alternate filename to use at run-time
vs compile time. If linking to a Rust dylib from C/C++ however, a
"libfoo.so -> libfoo-$hash.so" symlink may well be useful and in
this case DT_SONAME=libfoo-$hash.so would be required. More
mundanely, various tools (eg: dpkg-shlibdeps) complain if they don't
find DT_SONAME on shared libraries in public directories.
This patch passes -Wl,-soname=$outfile when building dylibs (and
using a GNU linker).
Forwarded: no
Gbp-Pq: Topic behaviour
Gbp-Pq: Name d-rustc-add-soname.patch
Our patch to mdbook installs symlinks to systems versions of font-awesome,
highlight, etc. Upstream mdbook otherwise doesn't use symlinks, so this
doesn't affect anything else that's already generated.
Forwarded: not-needed
Gbp-Pq: Topic build
Gbp-Pq: Name d-bootstrap-install-symlinks.patch
to find dependencies on windows targets in vendored crates. you will likely
need to remove some hunks from this patch after pruning dependencies, since
hopefully a few of the crates patched during early rebasing are eliminated.
windows-bindgen and windows-metadata should not be removed, they are needed for
the build and don't pull in windows-sys and friends.
Forwarded: not-needed
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Gbp-Pq: Topic prune
Gbp-Pq: Name d-0021-vendor-remove-windows-dependencies.patch
Description: remove all vendoring features of crates normally shipping bundled
C libs. that C code is stripped when repacking, so the features can't work
anyway.
Forwarded: not-needed
Gbp-Pq: Topic prune
Gbp-Pq: Name d-0010-cargo-remove-vendored-c-crates.patch
Description: Use https://github.com/infinity0/mdBook/tree/debian to help you rebase
the patch on top of a newer version. . Make sure the paths here match the ones
in debian/rust-doc.links
Forwarded: not-needed
Gbp-Pq: Topic prune
Gbp-Pq: Name d-0002-mdbook-strip-embedded-libs.patch
When the build is configured with `[rust] rpath = false`, we need to set
`LD_LIBRARY_PATH` (or equivalent) to what would have been the `RPATH`,
so the compiler can find its own libraries. The old `tools.mk` code has
this environment prefixed in the `$(BARE_RUSTC)` variable, so we just
need to wire up something similar for run-make v2.
This is now set while building each `rmake.rs` itself, as well as in the
`rust-make-support` helpers for `rustc` and `rustdoc` commands. This is
also available in a `set_host_rpath` function for manual commands, like
in the `compiler-builtins` test.
Josh Stone [Mon, 8 Apr 2024 22:04:44 +0000 (15:04 -0700)]
[PATCH] Fix UI tests with dist-vendored dependencies
There is already a workaround in `compiletest` to deal with custom
`CARGO_HOME` using `-Zignore-directory-in-diagnostics-source-blocks={}`.
A similar need exists when dependencies come from the local `vendor`
directory, which distro builds often use, so now we ignore that too.
Also, `issue-21763.rs` was normalizing `hashbrown-` paths, presumably
expecting a version suffix, but the vendored path doesn't include the
version. Now that matches `[\\/]hashbrown` instead.
Forwarded: yes
Gbp-Pq: Topic upstream
Gbp-Pq: Name u-avoid-blessing-cargo-deps-s-source-code-in-ui-tests.patch
When cfg(test), Config::parse doesn't parse a config.toml but uses default
values, failing when the initial rustc is needed. This is a workaround before
upstream issue gets solved.
Last-Update: 2023-03-29
Gbp-Pq: Topic upstream
Gbp-Pq: Name u-fix-get-toml-when-test.patch
cross_conmpile::alternate states it should only be used in test cases
after checking cross_compile::disabled(), which is missing here. these
tests fail despite setting CFG_DISABLE_CROSS_TESTS on i386, since both
the host and the alternate cross target would be i686 in that case.
Signed-off-by: Fabian Grünbichler <debian@fabian.gruenbichler.email>
Gbp-Pq: Topic cargo
Gbp-Pq: Name c-0003-tests-add-missing-cross-disabled-checks.patch
In Rust, library filenames include a version-specific hash to help
the run-time linker find the correct version. Unlike in C/C++, the
compiler looks for all libraries matching a glob that ignores the
hash and reads embedded metadata to work out versions, etc.
The upshot is that there is no need for the usual "libfoo.so ->
libfoo-1.2.3.so" symlink common with C/C++ when building with Rust,
and no need to communicate an alternate filename to use at run-time
vs compile time. If linking to a Rust dylib from C/C++ however, a
"libfoo.so -> libfoo-$hash.so" symlink may well be useful and in
this case DT_SONAME=libfoo-$hash.so would be required. More
mundanely, various tools (eg: dpkg-shlibdeps) complain if they don't
find DT_SONAME on shared libraries in public directories.
This patch passes -Wl,-soname=$outfile when building dylibs (and
using a GNU linker).
Forwarded: no
Gbp-Pq: Topic behaviour
Gbp-Pq: Name d-rustc-add-soname.patch
Our patch to mdbook installs symlinks to systems versions of font-awesome,
highlight, etc. Upstream mdbook otherwise doesn't use symlinks, so this
doesn't affect anything else that's already generated.
Forwarded: not-needed
Gbp-Pq: Topic build
Gbp-Pq: Name d-bootstrap-install-symlinks.patch
Avoid using #[cfg] on multiple individual function arguments
Attaching #[cfg] to individual arguments makes it look like the function
has five conditionally present arguments, and doesn't make it
immediately apparent that the first two are for the first argument and
the last three are for the second argument.
Split them into separate `let` statements for clarity.
In the process, factor out the common `.try_into().ok()?` from each.
to find dependencies on windows targets in vendored crates. you will likely
need to remove some hunks from this patch after pruning dependencies, since
hopefully a few of the crates patched during early rebasing are eliminated.
windows-bindgen and windows-metadata should not be removed, they are needed for
the build and don't pull in windows-sys and friends.
Forwarded: not-needed
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Gbp-Pq: Topic prune
Gbp-Pq: Name d-0021-vendor-remove-windows-dependencies.patch
Description: remove all vendoring features of crates normally shipping bundled
C libs. that C code is stripped when repacking, so the features can't work
anyway.
Forwarded: not-needed
Gbp-Pq: Topic prune
Gbp-Pq: Name d-0010-cargo-remove-vendored-c-crates.patch
Description: Use https://github.com/infinity0/mdBook/tree/debian to help you rebase
the patch on top of a newer version. . Make sure the paths here match the ones
in debian/rust-doc.links
Forwarded: not-needed
Gbp-Pq: Topic prune
Gbp-Pq: Name d-0002-mdbook-strip-embedded-libs.patch
Josh Stone [Mon, 8 Apr 2024 22:04:44 +0000 (15:04 -0700)]
[PATCH] Fix UI tests with dist-vendored dependencies
There is already a workaround in `compiletest` to deal with custom
`CARGO_HOME` using `-Zignore-directory-in-diagnostics-source-blocks={}`.
A similar need exists when dependencies come from the local `vendor`
directory, which distro builds often use, so now we ignore that too.
Also, `issue-21763.rs` was normalizing `hashbrown-` paths, presumably
expecting a version suffix, but the vendored path doesn't include the
version. Now that matches `[\\/]hashbrown` instead.
Forwarded: yes
Gbp-Pq: Topic upstream
Gbp-Pq: Name u-avoid-blessing-cargo-deps-s-source-code-in-ui-tests.patch
When cfg(test), Config::parse doesn't parse a config.toml but uses default
values, failing when the initial rustc is needed. This is a workaround before
upstream issue gets solved.
Last-Update: 2023-03-29
Gbp-Pq: Topic upstream
Gbp-Pq: Name u-fix-get-toml-when-test.patch
projects / rustc.git / log